All About Session and Session Cookie in Depth

सेशन स्टेट मैनेजमेंट एक ऐसी तकनीक है जिसका उपयोग यूज़र के डेटा को कुछ समय के लिए सर्वर पर स्टोर करके रखने के लिए किया जाता है, ताकि सर्वर यूज़र की पहचान बनाए रख सके। 

जैसा कि हम जानते हैं कि एचटीटीपी(HyperText Transfer Protocol) एक स्टेटलेस प्रोटोकॉल है तो प्रत्येक रिक्वेस्ट के बाद यूजर का इनफॉरमेशन नष्ट हो जाता है और सर्वर के पास यूजर का कोई स्थायी इनफॉरमेशन संचित नहीं होता है। 

यदि यूजर के इनफॉरमेशन को सर्वर को कुछ समय के लिए संचित करके रखना हो तो इसके लिए सर्वर स्टेट मैनेजमेंट की तकनीक का उपयोग करता है। इससे यूज़र की पहचान (identity) लगातार बनी रहती है। इसके अंतर्गत यूजर के इनफार्मेशन को की वैल्यू युग्म के रूप में सर्वर के मेमोरी के भीतर या किसी डाटाबेस के भीतर संचित करके रखा जाता है। चूँकि यूजर का इनफॉरमेशन सर्वर पर संचित किया जाता है अतः डाटा सुरक्षित रहता है लेकिन स्टेट मैनेजमेंट के लिए इतना ही पर्याप्त नहीं है। 

यूजर के इनफॉरमेशन को सर्वर साइड संचित करने के साथ-साथ यूजर से संबंधित एक सेशन आईडी जनरेट किया जाता है जिसे यूजर के पास कुकी के रूप में भेज दिया जाता है। यह सेशन आईडी सर्वर पर भी संचित करके रखा जाता है। जब कुकी को यूजर के पास भेजा जाता है तो उसमें सेशन आईडी के अलावा कुछ अन्य सेशन से संबंधित डाटा भी भेज दिया जाता है जैसे कुकी/सेशन का जीवनकाल, कुकी को जावास्क्रिप्ट  के द्वारा नहीं एक्सेस किया जाए इसके लिए HttpOnly Flag (ताकि JavaScript से एक्सेस न हो सके)  इत्यादि। ऐसा करने से सेशन कुकी सुरक्षित हो जाती है। 

ध्यान दीजिए कि कुकी में सेशन आईडी को एन्क्रिप्ट नहीं किया जाता है इसके विपरीत उन्नत रेण्डम नम्बर उत्पन्न करने की तकनीक(cryptographically strong random number generator)  का उपयोग करके सेशन आईडी जनरेट किया जाता है ताकि इसका अनुमान लगाना (guess करना) लगभग असंभव हो।

निष्कर्ष
  1. HTTP की stateless प्रकृति को संभालने के लिए सेशन स्टेट मैनेजमेंट आवश्यक है
  2. यूज़र डेटा सर्वर पर सुरक्षित रखा जाता है
  3. Session ID के माध्यम से यूज़र की पहचान बनाए रखी जाती है
  4. कुकी और सुरक्षा सेटिंग्स इस पूरी प्रक्रिया को सुरक्षित बनाती हैं


सेशन कुकी के भीतर सेशन का डाटा संचित किया जाता है या नहीं? 

सेशन कुकी के भीतर सेशन के सेशन आईडी को संचित रखना पर्याप्त है क्योंकि जब यह आईडी सर्वर को प्राप्त होता है तो यह सेशन से सम्बंधित डेटा का मेमोरी से निकाल कर काम कर सकता है। आइए इसे विस्तार से समझते हैं:
  • सामान्यतः Session Cookie के अंदर पूरा सेशन डेटा स्टोर नहीं किया जाता।
  • सेशन कुकी के भीतर केवल एक Session ID (सेशन पहचानकर्ता) रखा जाता है।

फिर सेशन डेटा कहाँ रहता है? 

सेशन से जुड़ा वास्तविक डेटा सर्वर साइड पर स्टोर होता है, जैसे:
  • Server memory (In-Memory)
  • Distributed cache (Redis, SQL Server आदि)
  • Database

Session ID की भूमिका क्या है? 

जब ब्राउज़र सर्वर को रिक्वेस्ट भेजता है, तो वह सेशन कुकी के माध्यम से Session ID भी भेजता है। सर्वर इस ID का उपयोग करके: 
1. अपने स्टोरेज (memory/cache/db) में संबंधित सेशन को ढूँढता है 
2. उससे जुड़ा डेटा निकालता है 
3. उसी डेटा के आधार पर रिक्वेस्ट को प्रोसेस करता है 
इसलिए यह कथन बिल्कुल सही है कि: “Session ID को कुकी में रखना पर्याप्त है, क्योंकि सर्वर उसी ID से पूरा सेशन डेटा प्राप्त कर सकता है।” 

ऐसा डिज़ाइन क्यों किया गया है? 

इसके पीछे कुछ महत्वपूर्ण कारण हैं: 
1. Security (सुरक्षा) अगर पूरा डेटा कुकी में रखा जाए:
  • यूज़र उसे देख या बदल सकता है
  • Sensitive data (जैसे user info) leak हो सकता है
2. Size Limit (आकार सीमा)
  • कुकी का आकार सीमित होता है (~4KB)
  • बड़े डेटा को कुकी में रखना संभव नहीं
3. Performance और Control
  • सर्वर साइड स्टोरेज अधिक नियंत्रित और तेज़ हो सकता है
  • Data expiration और management आसान होता है
एक महत्वपूर्ण अपवाद (Exception) कुछ आधुनिक तकनीकों जैसे JWT (JSON Web Token) में डेटा क्लाइंट साइड (कुकी/लोकल स्टोरेज) में रखा जाता है, लेकिन वह signed/encrypted होता है, यह पारंपरिक session-based approach से अलग है 

निष्कर्ष 

सेशन कुकी के भीतर पूरा सेशन डेटा संग्रहीत नहीं किया जाता, बल्कि केवल एक Session ID रखा जाता है। यह Session ID सर्वर को प्राप्त होने पर, सर्वर उससे संबंधित सेशन डेटा को अपने स्टोरेज (जैसे मेमोरी या डेटाबेस) से प्राप्त कर लेता है। इसलिए कुकी में केवल Session ID रखना ही पर्याप्त और सुरक्षित माना जाता है। 

क्या सेशन आईडी की सुरक्षा के लिए उसको एन्क्रिप्ट करने के पश्चात सेशन कुकी के भीतर संचित किया जाता है? 

सामान्यतः Session ID को “encrypt” नहीं किया जाता बल्कि Session ID एक random, unpredictable string होता है। इसे इस तरह generate किया जाता है कि कोई attacker इसका अनुमान न लगा सके। 

फिर सुरक्षा कैसे सुनिश्चित की जाती है? 

Session ID की सुरक्षा कई तरीकों से होती है: 
1. Randomness (अनुमान न लगाया जा सके)
  • Session ID cryptographically strong random generator से बनता है
  • Example: a8f5f167f44f4964e6c998dee827110c
इसलिए इसे encrypt करने की जरूरत कम पड़ती है 
2. Cookie Security Flags Session cookie पर ये flags लगाए जाते हैं:
  • HttpOnly → JavaScript access नहीं कर सकता (XSS protection)
  • Secure → केवल HTTPS पर भेजी जाएगी
  • SameSite → CSRF attacks को कम करता है
3. Session Expiry
  • Session ID की lifetime सीमित होती है
  • Idle timeout / absolute expiration लागू होता है
4. Session Regeneration
  • Login के बाद नया Session ID generate किया जाता है
  • इससे Session Fixation Attack रोका जाता है

क्या कभी encryption उपयोग होता है? 

कुछ frameworks (जैसे ASP.NET Core) में:Cookie को encrypt + sign किया जा सकता है लेकिन ध्यान दें यहाँ encryption पूरे cookie payload पर होता है सिर्फ Session ID पर नहीं, कुछ frameworks में पूरी कुकी को encrypt किया जा सकता है, परंतु यह आवश्यक नहीं कि केवल Session ID को अलग से encrypt किया जाए। 

सेशन कुकी के मेटा इन्फॉर्मेशन (जैसे कुकी का जीवन काल) सर्वर पर संचित किया जाता है या कुकी के भीतर ही? 

सीधा उत्तर है: कुकी का मेटा-इन्फॉर्मेशन (जैसे lifetime, expiry, domain, path आदि) कुकी के भीतर ही संग्रहीत होता है, सर्वर पर नहीं। अब इसे स्पष्ट रूप से समझते हैं। जब सर्वर ब्राउज़र को कुकी भेजता है, तो वह HTTP response header में कुछ इस प्रकार होती है: 
Set-Cookie: SessionId=abc123; Expires=Wed, 10 Apr 2026 10:00:00 GMT; HttpOnly; Secure; SameSite=Strict 

यहाँ ध्यान दें:
  • SessionId=abc123 → actual data (Session ID)
  • बाकी सब (Expires, HttpOnly, Secure, SameSite) → meta information
यह पूरा पैकेज ब्राउज़र (client) में ही स्टोर होता है। सर्वर साइड पर आमतौर पर केवल Session ID (key) और उसके साथ जुड़ा session data (value) होता है। सर्वर को कुकी के expiry या अन्य meta की जानकारी अपने आप नहीं रहती, जब तक कि वह अलग से न संभाले। 

फिर expiry कैसे काम करती है? 

यह पूरी तरह ब्राउज़र की जिम्मेदारी है:
  • जैसे ही कुकी expire होती है
  • ब्राउज़र उसे delete कर देता है
  • और अगली request में उसे सर्वर को भेजता ही नहीं

Session Cookie vs Persistent Cookie 

1. Session Cookie
  • Expires या Max-Age नहीं होता
  • ब्राउज़र बंद होते ही delete हो जाती है
2. Persistent Cookie
  • Expires या Max-Age सेट होता है
  • तय समय तक रहती है

महत्वपूर्ण बात (Advanced Insight) 

हालांकि कुकी का expiry client-side होता है, फिर भी: कई frameworks (जैसे ASP.NET Core) server-side पर भी session timeout रखते हैं इसका मतलब:
  • कुकी valid हो सकती है
  • लेकिन server पर session expire हो चुका हो
ऐसे में user effectively logout हो जाता है निष्कर्ष कुकी का मेटा इन्फॉर्मेशन (जैसे expiry, domain, path, security flags) कुकी के भीतर ही संग्रहीत होता है और ब्राउज़र द्वारा नियंत्रित किया जाता है। सर्वर सामान्यतः इन मेटा जानकारियों को स्टोर नहीं करता, बल्कि केवल Session ID और उससे संबंधित session data को अपने स्टोरेज में रखता है। 
अगले पोस्ट में हम इन सब बातो को प्रैक्टिकल रूप में ASP.NET Core के भीतर सेशन कुकी बना कर समझेंगे

टिप्पणियाँ

एक टिप्पणी भेजें

इस ब्लॉग से लोकप्रिय पोस्ट

Differences between in-process and out-of-process hosting models

ASP.NET Core: इन-प्रोसेस और आउट-ऑफ-प्रोसेस होस्टिंग मॉडल में अंतर ASP.NET Core में सेल्फ-होस्टिंग मॉडल और आउट-प्रोसेस होस्टिंग मॉडल दो अलग-अलग तरीके हैं जिनका उपयोग आप अपने वेब एप्लिकेशन को होस्ट करने के लिए कर सकते हैं। सेल्फ-होस्टिंग मॉडल सेल्फ-होस्टिंग मॉडल में, ASP.NET Core एप्लिकेशन अपने आप में एक वेब सर्वर की भूमिका निभाता है। इसका मतलब है कि एप्लिकेशन अपने आप HTTP रिक्वेस्ट को सीधे हैंडल करता है और उन्हें प्रोसेस करता है। सेल्फ-होस्टिंग के लिए Kestrel नामक एक क्रॉस-प्लेटफ़ॉर्म वेब सर्वर का उपयोग किया जाता है। आउट-प्रोसेस होस्टिंग मॉडल आउट-प्रोसेस होस्टिंग मॉडल में, ASP.NET Core एप्लिकेशन एक अलग प्रोसेस में चलता है, और एक बाहरी वेब सर्वर (जैसे कि आईआईएस या एनजिनएक्स) HTTP रिक्वेस्ट को प्राप्त करता है और उन्हें एप्लिकेशन को फॉरवर्ड करता है। इस मॉडल में, एप्लिकेशन और वेब सर्वर अलग-अलग प्रोसेस में चलते हैं। अब इनके बारे में विस्तार से समझते हैं - 1. इन-प्रोसेस होस्टिंग (In-Process Hosting) कार...
Read more »

Web Fundamental Concepts in Hindi for Beginners - FAQs with their Answers Part-1

List of Consolidated Questions Question 1. वेब एप्लीकेशन को होस्ट करने की आवश्यकता होती है जबकि डेस्कटॉप एप्लीकेशन के साथ ऐसा नहीं होता है ऐसा क्यों? Question 2. वेब एप्लीकेशन को होस्ट करने के लिए एक वेब सर्वर की जरूरत होती है क्यों? इसके अलावा वेब एप्लीकेशन को डाटाबेस सर्वर की भी आवश्यकता पड़ती है क्यों? Question 3. वेब सर्वर के अलावा और किन-किन प्रकार के सर्वर की आवश्यकता वेब एप्लीकेशन को पड़ती है? Question 4. एक वेब एप्लीकेशन को एक से अधिक सर्वर पर कई बार क्यों होस्ट किया जाता है? Question 5. वेब एप्लीकेशन और वेब सेवा में क्या अंतर है या दोनों एक ही चीज है? Question 6. क्या यह सच है कि एक वेब एप्लीकेशन एक या एक से अधिक वेब सेवाओं का उपयोग कर सकता है? Question 7. वेब एप्लीकेशन के संदर्भ में गेटवे क्या होता है? Question 8. ...
Read more »

Introduction to ASP.NET Core and Web Frameworks

वेब एप्लीकेशन और .NET Core का परिचय वेब एप्लीकेशन हर जगह उपलब्ध हैं, चाहे वह सोशल मीडिया हो या आपका फ़ोन; हर जगह आपको वेब एप्लीकेशन दिखाई देंगे। वेब एप्लीकेशन के पीछे की दुनिया सर्वर की दुनिया है। सर्वर पर कोई वेब एप्लीकेशन होस्ट किया जाता है, तत्पश्चात वेब एप्लीकेशन रन होता है। .NET Core को आधुनिक युग की आवश्यकताओं के अनुसार डिज़ाइन किया गया है। चाहे कोई साधारण सा वेबसाइट हो या कोई जटिल ई-कॉमर्स एप्लीकेशन अथवा डिस्ट्रीब्यूटेड माइक्रो सर्विसेज, एक बार जब आप .NET Core सीख जाते हैं तो इस तरह के कोई भी एप्लीकेशन आप बना सकते हैं। अब सवाल है कि .NET Core क्या है? ASP.NET Core माइक्रोसॉफ्ट का नया वेब फ्रेमवर्क है जिसकी सहायता से विभिन्न प्रकार के वेब एप्लीकेशन को बनाना बहुत ही सरल है। माइक्रोसॉफ्ट ने ASP.NET Core को जून 2016 में रिलीज़ किया था। इसके बाद निरंतर माइक्रोसॉफ्ट की टीम ने .NET Core में सुधार करके या अपग्रेड करके बाजार में नए-नए वर्जन जारी किए हैं. वेब फ्रेमवर्क क्या है? ...
Read more »